This call to processFooter introduces a race condition. It's now executed before the tasks in the ExecutorService are guaranteed to be complete. For formats like JSON, this can lead to a corrupted output file (e.g., a closing ] written before all objects). This line should be removed. The call should be moved into the finally block after awaitTermination succeeds, as I've suggested in another comment.

I have made changes based on feedback in e84bc49.

As mentioned in my other comment, processFooter should be called here, after awaitTermination has successfully completed. This ensures all data has been written before the footer is added. The suggestion below moves the call here and also adds the necessary handling for IOException, which processFooter can throw.

        try {
          if (executorService.awaitTermination(Long.MAX_VALUE, TimeUnit.NANOSECONDS)) {
            logger.info("All tasks completed");
            processFooter(exportOptions, tableMetadata, bufferedWriter);
          } else {
            logger.error("Timeout occurred while waiting for tasks to complete");
          }
        } catch (InterruptedException e) {
          Thread.currentThread().interrupt();
          logger.error("Interrupted while waiting for executor termination", e);
        } catch (IOException e) {
          logger.error("Error writing footer: ", e);
        }

I have made changes based on feedback in e84bc49.

@gemini-code-assist @inv-jishnu I think there's still a potential race condition.

Even after awaitTermination() times out and Thread.currentThread().interrupt() is called, busy threads might be still running. If those threads are still executing when processFooter() is called, we could have data corruption.

How about guarding processFooter() with executorService.isTerminated() to ensure all threads have actually completed?

You've raised a very important and valid point, @komamitsu. There is indeed a potential race condition in the current implementation regarding processFooter().

My initial suggestion (in comment #1) aimed to address this by placing processFooter() inside the if (executorService.awaitTermination(...)) block. This would ensure that the footer is only processed if all tasks completed successfully within the given timeout. If awaitTermination() returns true, it implies that executorService.isTerminated() would also be true at that point, meaning all tasks have indeed completed.

However, in the current code, processFooter() has been moved to be called unconditionally after the awaitTermination block (at lines 124-127 in the full patch). This reintroduces the race condition you've identified: if awaitTermination() times out (returns false) or an InterruptedException occurs, processFooter() will still be called while tasks might still be running or in an inconsistent state, potentially leading to data corruption.

To resolve this, processFooter() should be moved back into the if (executorService.awaitTermination(...)) block, similar to my original suggestion. This ensures it's only executed when all tasks are confirmed to have completed. The IOException handling for processFooter should also be included within that conditional block.

Since the processFooter call is now outside the lines highlighted by this comment (lines 112-121), I cannot provide a direct code suggestion here. However, the necessary change is to move the try-catch block for processFooter (currently at lines 124-127) to be immediately after logger.info("All tasks completed"); (line 115), and ensure its IOException is handled there.

@komamitsu san,

I have moved processFooter section inside the if condition for the executorService.awaitTermination(...) as suggested in 27b5484.
Thank you.

@inv-jishnu Let me ask this just in case. Is it okay to always call processFooter() even when something fails (e.g., fetchDataChunk() throws an exception) ?